o use manner. 
BSPR: 

Currently, it is common in mail processing for mail piece data to be handled 
utilizing a file-based system (i.e. using a flat ASCII file to hold all 
database driven insertion and mail piece tracking information). A 
client/server concept involves replacing flat files with a database server 
which maintains indices and relations between various data fields, as 
described 

further hereinbelow. Also as described further hereinbelow, utilizing a 
client-server concept, as according to the present invention, allows an 
interface to be developed for client programs to be able to read database 
driven insertion (DDI) data from the database and write mail piece tracking 
data back to the database. 

BSPR: 

Database driven insertion (DDI) is currently being accomplished in 
conventional 

mail processing by storing mail processing instructions in a flat ASCII file, 
reading an account number fi-om paper via a laser scanner, calculating the 
offset of the data in the file that corresponded to the account number read, 
and reading the data at that offset point into the mail processing equipment. 
Mail piece tracking has been accomplished by storing information about a 
mailpiece back into the database driven insertion (DDI) file, or possibly a 
separate file whenever the mailpiece processing was complete. This was, 
and 

still is, the industry norm because it is believed that a database is not 
capable of keeping up with the read and write rates required for multiple 
mail 

processing machines. In contrast to this norm, the present invention, 
however, 

can and does keep up with the read and write rates required for multiple 
mail 

processing machines using the aforementioned client/server concept, as 
described further hereinbelow. 

BSPR: 
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mail piece tracking system, method, and computer program 
product is disclosed. A database is populated with database 
driven insertion data comprising instructions for handling 
mailpiece material. A server manages the database by 
responding to requests for mail processing instmctions from 
clients and storing mailpiece data received from chents. A 
scarming device reads key code marked mailpiece material 
in which the key code corre^onds to a database location 
containing instructions for handling mailpiece material. A 
chent processor receives the key code from the scanning 
device, and transmits a request to the server for accessing the 
database location containing the instructions for handling 
mailpiece material. ITie server retrieves the instructions for 
handling mailpiece material, and transmits the instructions 
to the chent. The client causes the performance of a mail 
processing task in accordance with the instructions, gathers 
mailpiece tracking data as the mailpiece material is 
processed, and forwards mailpiece tracking data to the 
server. The database information is accessible to report 
writing and generating software applications which cull data 
pertaining to a given mail processing job into a desired 
format. 
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1 

CLIENT-SERVER SYSTEM, METHOD AND 
COMPUTER PRODUCT FOR MANAGING 
DAIABASE DRIVEN INSERTION (DDI) AND 
MAIL PIECE TRACKING (MPT) DATA 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is related to and claims the benefit of the 
U.S. Provisional Patent ^plication entitled "A Client- 
Server System and Method Of Managing Database Driven 
Insertion pDI) and Mail Piece Tracking (MPT) Data", filed 
on Oct. 27, 1998, Ser. No. 06/105,804 and is a divisional of 
U.S. patent application Ser. No. 09/183^11, filed Oct. 30, 
1998 (U.S. Pat. No. 6,119,051). 

FIELD OF THE INVENTION 

The present invention relates generally to maniifacturing 
environments that wish to relate large amounts of informa- 
tion to a small identifier. More specifically, the present 
invention relates to a client-server system, method, and 
computer program for managing database driven insertion 
(DDI) and mail piece tracking (MPT) data for holding and 
managing mailroom data in a consistent and easy to use 
marmer. 

BACKGROUND OF THE INVENTION 

Currently, it is common in mail processing for mail piece 
data to be handled utilizing a file-based system (i.e. using a 
flat ASCII file to hold aU database driven insertion and mail 
piece tracking information). A client/server concept involves 
replacing flat files with a database server which maintains 
indices and relations between various data fields, as 
described further hereinbelow. Also as described further 
hereinbelow, utilizing a cHcnt-scrvcr concept, as according 
to the present invention, aUows an interface to be developed 
for client programs to be able to read database driven 
insertion (DDI) data from the database and write mail piece 
tracking data back to the database. 

Database driven insertion (DDI) is currently being accom- 
plished in conventional mail processing by storing mail 
processing instructions in a flat ASCII file, reading an 
account niimber from paper via a laser scaimer, calculating 
the offset of the data in the file that corresponded to the 
account number read, and reading the data at that ofiEset point 
into the mail processing equipment. Mail piece tracking has 
been accomplished by storing information about a mailpiece 
back into the database driven insertion (DDI) file, or pos- 
sibly a separate file whenever the mailpiece processing was 
complete. This was, and still is, the industry norm because 
it is believed that a database is not capable of keeping up 
with the read and write rates required for multiple mail 
processing machines. In contrast to this norm, the present 
invention, however, can and does keep up with the read and 
write rates required for multiple mail processing machines 
using the aforementioned client/server concept, as described 
further hereinbelow. 

Database driven insertion (DDI) data typically describes 
to iiKlividual mail processing inserters which inserts to feed, 
how many sheets are in an account, what actions the inserter 
is to perform on the account, what address should be printed 
on the envelope, and/or other information as apparent to 
those of skiU in the art. 

Mail piece traddng (MPT) data typically describes what 
actually happened to the account during processing, i.e. 
what machine processed it, when the machine started pro- 
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cessing it, when the machine finished processing it, which 
operators were running the machine, which inserts fed, 
and/or other information as apparent to those of drill in the 
art. 

5 Using a database under a client/server architecture (as 
opposed to a flat ASCII file) for insertion and tracking has 
many significant advantages which wiU be readily appreci- 
ated by those of skill in the art. Clients (which can comprise 
mail inserters, mail sorters, printers, other applications, 
10 and/or other suitable cUents as recognized by those of skill 
in the art of mail processing) can request and receive only 
the information they need which decreases the overall load 
borne by the communications network. Other clients (report 
generators) can create reports much easier with well known 
15 database reporting tools. The server provides a common 
repository for aU mail piece tracking and database driven 
insertion data, which, in turn, allows management from one 
computer and location, i.e. centralized operation. The data- 
base server provides excellent file locking and read/write 
20 contention protection superior to that of ASCII flat files. The 
server also provides services to inform clients whether a 
record was updated ^imdemeath" it. This provides site-wide 
duplicate checking for aU mailpieces to ensure there are no 
duplicate mailpieces being processed. AdditionaUy, the data- 
25 base server enforces data consistency. The server will not 
allow clients to write "invalid" data into the database. This 
is very diflBcult to enforce in file-based systems. The server 
fijxther provides "stored procedures" which allow the server 
to change its functionality without necessarily modifying 
30 client code. Other advantages can also exist as recognized by 
those skilled in the art. 

In view of the above, there remains much room for 
improvement in the art, particularly for a i^w system and 
method of "publishing" and "recording" database driven 
-^^ insertion and mail piece tracking data. 

DISCLOSURE OF THE INVENTION 

In accordance with the present invention, a novel client- 
server system, method, and computer program for managing 
40 database driven insertion (DDI) and mail piece tracking 
(MPI) data for holding and managing mailroom data in a 
consistent and easy to use manner is provided. "Managing" 
of data according to the present invention refers to a system 
that controls, utilizes, tracks, and reports on aU a^>ects of 
45 database driven insertion and mail piece tracking data. By 
the client/server database ardiitecture for managing data- 
base driven insertion and mailpiece traddng in a mail 
processing environment according this invention, a cus- 
tomer initially sets up a mail processing site by defining 
50 within the client/server architecture running database driven 
insertion and mail piece traddng system parameters such as 
Users, Privileges^ JobSetups, Materials, etc., before any 
actual mail processing occurs. Next, the customer generates 
data (generally in a mainframe environment) that is intended 
55 to be printed and mailed. The data is run through a utility 
like BeU & HoweU's Transformer*™ or their own custom 
software to create a "side file" that contains the database 
driven insertion information required by a mail processing 
insertion device. Each print run has a matching side file 
60 generated for it. Material is printed and the side file is 
loaded/inducted into the database driven insertion and mail 
piece traddng system. The customer physically conveys the 
printed material to the inserter, loads the mail processing job 
currendy programmed, places the materials caUcd for by the 
65 mail processing job (e.g., inserts, printed materials, 
envelopes, etc ... ) into the correct locations, and begins 
running the mail processing job. As a mail processing 
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inserter reads each reader code or key that has been strate- torn written software running on the client machines. The 

gically placed on the niailpiece materials, the inserter makes hardware is generally Intel Pentium™ II class generic per- 

a request for the database driven insertion data associated sonal computer boxes. 

with that particular key from the database. The database It is to be understood that the present invention illustrated 
sends the insertion data back to the inserter, which uses the 5 herein is readily implementable by those of ordinary skill in 
data to determine what actions to perform on this particular the art as a computer program product having a medium with 
account. As each mailpiece leaves the inserter, mail piece a computer program embodied thereon. Ibe computer pro- 
tracking data is written into the database associated with gram product is capable of being loaded and executed on the 
each database driven insertion record that records, for appropriate computer processing device(s) in order to carry 
instance, the Machine, Operators, Time, Date, JobSetup, lo out the method or process steps described. 
Inserts Fed, etc., for each mailpiece. ^^^^^g ^ applications on the mainframe 

It is therefore an object of the present mvention to provide side send print images from a host mainframe 40, for 

a novel client-server system, method, and computer program instance, to printers 50, and IntellaSert™ Data File (IDF) 

for managing database driven insertion (DDI) and mail piece data to the database server computer 10. Once the material 

tracking (MFI) data for holding and managing maikoom 15 ^ panted on by the printers 50 (v^diich can be monitored by 

data in a consistent and easy to use manner. a reconciliation station), the printed paper is presented to 

It is another object of the present invention to store all mail processing finishing equipment, sudi as, for instance, 

types of data in the database driven insertion server that are mail processing inserters 60. The mail processing finishing 

related to the other types of data in a way that makes equipment 60 requests information about the accounts it is 

generating very flexible and detailed reports very easy. about to process from the database server 10, using a small 

It is a further object of the present invention to be able to encoded in the accoimt barcode, and uses the informa- 

modify instructions regarding the processing of each mail- tion in the data file to continue processing the account. When 

piece right up until the time the mailpiece is placed on a the account has been completely processed (either rejected, 

machine for processing. removed, or ready to mail), the finishing equipment 60 

It is a still further object of the present invention to ^ ^P^^^^ d^i^bas^ with a complete disposition of the 

generate a standard postal manifest that details aU pieces ^^^^^ ^^^^ ^^^^ ^^^^ ^ 

processed and the amount owed the post office. available at all tunes to users havmg access to the supervisor 

, . .„ ^ . , - n ^ client computer 30. Once processing has been completed. 

It is a stiU further object of the present mvention to supervisor chent computer 30 can create a manifest to 

maflt^that^dn Pro«=ssed properly and 30 p^^ent to the United States Postal Service (USPS), and for 

ma pieces a i no process proper y. pieces that were destroyed during processing, it can feed 

Some of the objects of the invention having been stated, the pertinent data back to the host to generate reprint 

other objects will become evident as the description material and new IDF data. Alternately, supervisor client 

proceeds, when taken in connection with the accompanying computer 30 can send data to a local "Winserter"-type mail 

drawings described below. 35 p^cessing device to create reprints locaDy. This allows 

BRIEF DESCRIPnON OF THE DRAWINGS ^"^^^^'^ ^ ^^^^ ^ ^ '^'^^ "'^^^^^ ^°°P" f^*^^^"* 

The description of the present invention describes ser- 

The foregoing advantages and features of the present vices provided by the database server computer 10 and 

invention will be appreciated more fully from the following ^ application interfaces provided for client applications. These 

description with reference to the accompanying drawings in services are intended to provide all the basic services 

wbich: available in the software system design, including data file, 

FIG. 1 illustrates a client/server architecture capable for database driven insertion, historical reports, real time moni- 

use with the present invention. toring of machinery, operators, jobs, shifts, inserts tracking 

and chargeback, manifesting, reprinting, and/or other suit- 

BEST MODE FOR CARRYING OUT THE able services apparent to those of skiU in the art, while 

INVENTION adding the ability to significantly extend the feature set, all 

The present invention now is described more fully here- without harming backwards compatibility, 

inafter with reference to the accompanying drawings, in A dataset, according to the present invention, is a named 

which preferred ernbodiments of the invention are shown. 50 compilation of related data stored on the server. Datasets are 

This invention may, however, be embodied in many different composed of ordered records, which are accessed by a 

forms and should not be construed as limited to the embodi- record identifier. Conceptually, datasets can be envisioned as 

ments set forth herein; rather, these embodiments are pro- virtual files which support normal file services such as create 

vided so that this disclosure wiU be thorough and complete, file, open file, close file, delete file, read record, write record, 

and will fully convey the scope of the invention to those 55 and append record. Additionally, datasets have the ability to 

skilled in the art. delete records, provide multiple views of records, create a 

Referring now to FIG. 1, one possible client/server archi- °ew dataset based on an existing dataset, and some search 

tecture is shown which includes a database server computer criteria among other abilities. All datasets have one thing in 

10 used as the central repository of all data, a machine client common, namely, each dataset record has an attribute caUed 

computer (console) 20, a supervisory computer (supervisor) 60 "RecordlD". Ihe "RecordED" field defiines the order of 

30, and a computer network for operatively linking every- records in a dataset. The attribute "RecordlD" may be stored 

thing together. Solid lines represent electronic data flow inside the record, or may be implicitly designed by the 

whfle dashed lines represent physical paper or material flow dataset itself. In either case, users of a dataset need only 

throughout FIG. 1. The preferred embodiment presently uses know that every record "knows** its position, and every 

Microsoft Windows™ NT Server 4.0 software, Interbase™ 65 dataset "knows" its order. 

Server 5.01, and custom written software running on the A record is the basic element of a dataset This is the 

server machine and Interbasc™ client software and/or cus- smallest element that can be modified in a dataset. Note that 
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a record from a clieot point of view, and a record from a (but is not limited to) address information for printing on 

server point of view may be different for both the read and envelopes, which inserts to drop on this individual account, 

write cases. Clients may view a record as only a very small whether this account should be stapled, etc. Of particular 

number of fields, whereas the server may actuaUy have interest is a smaU piece of the data that allows inserts to be 

many fields for every record. As long as the client fields arc 5 ^^^^ individuaUy. 
a subset of the server fields, the server will send only the 

fields requested back to the chenL The term "stream" relates to input devices, sudi as 

A RecID is the basic "ke/* column for any dataset. The continuous forms cutters and cut ^eet feeders on a mail 

word "key" is emphasized, because this in no way implies processing inserter. For instance, a mail processing inserter 

that datasets are indexed databases. It is meant to infer the ^^^^ f^^^ ^ ^ ^^^^ 

frmction of a key field. All dataset records have a RecordID 0) streams. Hence, streamSheetOl, streamSheetOZ, and 

which starts at 1, and increases sequentially aUowing ele- streamSheet03 in the data file fields are filled. By 

ments of the dataset to be accessed by clients using the read convention, the most "upstream" mail processing device is 

record, update record, delete record, insert record, append ^5 stream 1. 

record, open dataset, close dataset, seek record, and tell Another feature of the present invention is its ability to 
record type methods available in the standard "C" File/IO provide for duplicate checking. As the client inserter "fin- 
function set. Note that the actual order of data records in the ishes" each mailpiece, the disposition of the mailpiece is 
dataset is both unknown and irrelevant. Unknown because saved in the data file data set via the data file account ID. The 
the server can implement it in any way it chooses, and ^ database driven insertion client can now provide real-time 
irrelevant because the server's only constraint on returning duplicate checking for the client inserter. If any other 
the dataset record to the client is that it happens "fast madiine on the network has processed or is currently 
enough". processing the mailpiece in question, the "latest" copy of the 
Views are defined by the services layer to provide data of 25 ™^P^^ will be deemed dupUcate. A warning message wiD 
interest from a dataset. A view defines all the fields needed 0° client computer screen, and the mailpiece will 
from a record in a dataset. A record in a dataset can have ^ targeted for the reject bm. 

many views defined simultaneously, and the data needed by It always has been and will always be possible for a 

the client defines which view is used. There are two (2) main printer operator or other worker(s) on the mailroom floor to 
uses for views in the client services. In the case of reading ^ introduce duplicate copies of already existing material into 

records from a dataset, the view defines the set of fields the the processing enviroimient. To detect and remedy these 

client wants the server to return for each record read. In the problems as soon as possible, the data file (IDF) system 

case of writing records from a dataset, the view defines the includes real-time duplicate dieddng software. Overall, 
set of fields the client must send to the server for each record 35 there should be no instances where the data file system does 

written. not detect a duplicate accouint. In nearly all cases, it will 

DDM stands for device and data management and refers detect and reject them in real-time. In some cases where 

to a (set of) client and server computer(s) that contain a large duplicate accounts are being processed within one (1) 

set of data relating current documents and past documents, minute of each other on different inserters within the same 

along with tools to allow management of this data. The network, the system will not be able to warn the operator of 

database server computer will never serve file or print the duplicate until the second of the duplicate accounts exits 

services, as its only purpose is to provide data services the machine. 

through a suite of applications. These applications will be When two or more machines process the same data with 

network communication based. overlapping material the printer operator backs up the print 

One feahire of the present invention is termed the client job between stacks of paper. Database driven insertion 

developers kit (CDK). It is an application programming clients would not be able to detect these errors by 

interface which allows a client to be developed using any themselves, since the account sequencing information would 

platform that has an Interbase™ client library available. The be correct. Depending on how close in time the various mail 

client developers kit application programming interface processing machines processed the material, this case would 

gives access to data ofinterest without having to know about be caught either by the "Server Reads Data" case or the 

or understand the details of the database. "Server Writes Data" case. 

Mail piece tracking refers to, inter alia, a client's ability Should a stack of material on a single machine have 
to report the disposition of a mailpiece without necessarily 55 duplicate material (from a printer rollback, for example) in 

being able to use the database driven insertion data defined the middle of the stack, the database driven insertion client 

in a record. This feature can be used for reprint generation would catch the first duplicate, because the account 

and for generating manifests. sequence there would be invalid. If more than one account 

Database driven insertion and processing data file were duplicated, however, the rest of the accounts would 

(process directive file) are terms referring generally to the process normally. Duplicate checking detects this problem 

concept of having a electro-mechanical piece of equipment in the "Client Receives Data" case, the "Server Reads Data" 

(an inserter, for example) associate large amounts of data case, or the "Server Writes Data" case, depending on the 

with a small "key" or identifier printed on the material via tm^ng. 

codes (or other machine readable method). The data referred 55 In the "Server Reads Data" case, when the server receives 

to by the "key" is changeable up to the moment the data is a request for an account record, it diecks the final destina- 

read and "placed" on the equipment. The data can supply tion field of that record. If it is *NP (not processed), *OR' 
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(operator removed), or 'R2^ (reject bin), the server changes should not be processed, and wants to require the 
nothing and passes the data record down to the client for inserter operator to remove the account from the mail- 
processing. If the final destination is anything different than ing. 

those mentioned above, the server sets the target destination When the client reports a finished account to the server, 
of the account to *DP' (duplicate), which will result in the ^ the server determines the final disposition of the mailpiece 

account being sent to the reject bin. The cHent, whenever it by comparing the "current" disposition with the "new" 

receives a *DP' target destination, can inform the operator disposition. Based on these two values, it chooses to incre- 

that a duphcate account wiU be rejected. ment (or not) a value called the "Duplicate Counr (this is 
Inthe"ServerWritesData"case, when the server receives lo the first value in each cell in the table below) and decides 

data back from the client to write into the data file database, whether to save the "new" data into the table (the second 

it will know whether the record in the database has been value in each cell of the table below). Lastly, the server 

modified. If it has been modified, the server checks to see if returns a status for every write, and if the status is affected 

the final destination is set to an invafid destination. If it is, by the destinations, the status is listed in the third row of 

it will set the final destination of the record to 'DP' each cell. The following table of new and existing final 

(duphcate), and send a message to the client to inform the destinations describes the rules governing every possible 

operator that a duphcate mailpiece exists. new and existing final destination: 

TABLE 1 

Duplicate Destinations 

EXISTING FIKAL DESmsrAnON 

SH SD OW RX OR NP LH 



SH 


1 


1 


1 


0 


0 


0 


1 




No 


No 


No 


Yes 


Yes 


Yes 


No 




ERR_X»UP 


ERR_DUP 


ERR_DUP 


ERR^ON 


ERR_NON 


ERRJSrON 


ERR^XH 


SD 


1 


1 


1 


0 


0 


0 


1 




No 


No 


No 


Yes 


Yes 


Yes 


No 




ERR__DUP 


ERR_DUP 


ERR^DUP 


ERR_NON 


ERR^NON 


ERR_NON 


ERR_LH 


ow 


1 


1 


1 


0 


0 


0 


1 




No 


No 


No 


Yes 


Yes 


Yes 


No 




ERR_DUP 


ERR_DUP 


ERR_DUP 


ERR_NON 


ERR_NON 


ERR_NON 


ERR_iH 


RX 


0 


0 


0 


0 


0 


0 


0 




No 


No 


No 


Yes 


Yes 


Yes 


No 




ERR_NON 


ERRJSTON 


ERR^NON 


ERR_NON 


ERR_NON 


ERR_NON 


ERR^NON 


OR 


0 


0 


0 


0 


0 


0 


0 




No 


No 


No 


Yes 


Yes 


Yes 


No 




ERR_NON 


ERR^NON 


ERR_NON 


ERR^ON 


ERR_NON 


ERR_NON 


ERR^NON 



In the "Client Receives Data" case, when the chent 
receives a record fi-om the server, it ched^ all the accounts 
that it is currently processing. If it finds a matching account, 
it will set the target destination of the new duphcate accoumt 
to *DP'. This account will eventually go to the reject bin. 

The abbreviations used in the tables below are explained 
defined as: 

SH Standard Handhog (The destination(s) for "Good" 

mailable mail). 
SD Security Divert. (The destination(s) for "Special" 

mail) 

OW Overweight Divert. (The destination(s) for material 
that is too heavy or too thick to be mailed). 

RX Reject Divert. (The destination(s) where "bad" or 
damaged material is sent). 

OR Operator Removed. (The destination where material 
that is removed by the operator is sent). 

NP The initial or Not Processed destination. This flag 
indicates the mailpiece must be recreated. 

DP Duphcate Account. This indicates that the account 
was processed at least twice (i.e. more than one copy of 
this account went to 'SH', *SD% or 'OW. 

IM Late Hold. This indicates that the user (via a pre- 
processing function) has determined that the account 



When data file data is read from the database, if the 
duphcate coimt of the record is greater than zero, the final 
destination is returned as 'DP', regardless of what the actual 
final destination in the data is. The only exception to this is 
where the final destination is 'LH'. In this case, the final 
destination returned is 'LH*, regardless of what the actual 
duplicate coimt is. The following table delineates these 
rules: 

TABLE 2 

Di^licate Destination Read Rules 
FINAL DESrriNAnON 





SH 


SD 


ow 


RX 


OR 


LH 


NONE 


0 


SH 


SD 


ow 


RX 


OR 


LH 


NP 


>0 


DP 


DP 


DP* 


DP* 


DP* 


LH 


DP* 



Note that there should never be final destinations of OW, 
RX, OR, or NONE with a duphcate count greater than zero. 
These cases are handled as data integrity errors. 

When a user "fixes" the problem with a duphcate (or Late 
Hold), the chent can call the "ReleaseDupHcate" apphcation 
65 progranmung interface which will decrement the duplicate 
count, return the current duphcate count and a status code. 
The table describing these rules is as follows: 
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TABLES 



DUPE 



Release Duplicate Actions 
FnSTAL DESTTNAnON 



COUNT SH 



SD 



OW 



RX 



OR 



LH 



NONE 



<2 ERR_NON 
DC«0 

>1 ERR_DUP 
DC — 



ERR^NON ERR_NON ERR_NON ERR_NON ERR__NON ERR_NON 

DC = 0 DC = 0 DC = 0 DC = 0 DC = 0 DC = 0 

ERR._DUP ERR_DUP ERR_NON ERR^NON ERR_IiI ERR_NON 

DC— DC— DC = 0 DC = 0 DC— DC=0 



Note that the item in each cell is the error code. The 
second is the action to be performed on the Duplicate Count 
(DQ. 

The system and methodology of the present invention can 
be ilhistrated by way of the following example, which is 
described for illustrative purposes only and is not intended 
to be exhaustive of the potential applicability of the present 
invention. 

ILLUSTRATIVE EXAMPLE 

Consider an organization that wishes to print and mail a 
large batcb of material to a set of its customers. First, the 
organization generates print images within a mainfirame host 
computer, for instance. The print images, representing all or 
part of the mailpiece to be sent, are forwarded to a printer or 
printers to be printed on documents such as paper sheet 
articles. Thus, the content to be mailed is converted from 
electronic image to physical paper ready to be manipulated 
in a mail processing enviromnent. The mainframe host 
computer, in this example, also generates database driven 



dehnes (i) reader codes printed on the material, (ii) the 
15 "mode" of the machine, (iii) which inserts are loaded 
into the mailing machine, and (iv) the methods of 
stapling, folding, printing, etc. for the machine. 

(2) Physically loading the material on the mail processing 
20 machine. 

(3) If the "Name" of the database driven insertion (DDI) 
data is not specified on the reader codes, the user must 
select which set of database driven insertion data to use 
&om the database. 

25 

(4) At this point, the machine begins processing the paper, 
following the "Job Level" instructions contained in the 
Job Setup, and the "Accoimt Level" instructions con- 
tained in the database driven insertion data. 

30 , Database driven insertion data for the following eight (8) 
accounts is generated by host computers and sent to the 
database server computer. The database server computer 
stores the data in the following manner: 



TABLE 4 



Database driven insertion Accxtunt Data 



Tray 


IDF 


Doc 


Ibrget 


Tray 










Str 


Str 


Str 


str 


ID 


ID 


ID 


Dest 


Dest 


DPBC 


Pull Key 


User Field 


Proc. Dir 


0 


1 


2 


3 


4464 


160 
"AA" 


3643 


"SET' 




"1111111 
1111" 


"0000000056721475" 


"00000000567 
21475" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 


4464 


160 
"AA" 


3644 


"SH" 




"111111 
11111" 


-0000000059049304" 


"00000000590 
49304" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 


4464 


160 
-AA" 


3645 


"Sir 




"lum 
mil" 


"0000000059038117" 


"00000000590 
38117" 


"NNN^fNNNNNYNNNNNN NNNN" 


3 


0 


0 


Q 


4464 


160 
"AA" 


3646 


"SH" 




"111111 
mil" 


"0000000059052456" 


"00000000590 
52456" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 


4464 


160 
-AA" 


3647 


"Sff* 




"iiim 
mil" 


"0000000059691501" 


"00000000596 
91501" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 


4464 


160 
-AA" 


3648 


"SH" 




"lum 
mil" 


"00000000576S1793r 


"00000000576 
81793" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 


4464 


160 
"AA" 


3649 


"SH" 




"111111 
mil" 


"0000000059307249" 


"00000000593 
07249" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 


4464 


160 
-AA" 


3650 


"Sir 




"iiim 
mil" 


"0000000058294141" 


"00000000582 
94141" 


"NNNNNNNNNYNNNNNN NNNN" 


3 


0 


0 


0 



insertion data that is forwarded to the organization's mail- 
room database server. The database driven insertion data is 
then inducted or imported into the database driven insertion 
and mail piece tracking system. 50 

After the material has been printed and the data has been 
populated into the database, the mail processing machines 
begin processing the printed material. An operator of the 
mail processing machine initiates the following process: 

(1) Selecting and loading a "Job" for the machine. The job 65 
is defmed in the database and was created previously by 
a user with authority and privilege to do so. The job 



The above table data is defined as foUows: 

Tray ID Information about the mailing tray the mailpiece 
belongs to. 

IDF ID The IDF data group this mailpiece belongs to. 

Generally, an IDF corresponds to a print run. 
Target Dest The desired "destination" of the mai^iece on 

the mailing machine. This would correspond to "SH" 

(Standard HandKng),"Sir (Security Divert), "OW" 

(Overweight). 
Tray Dest Information necessary to print a tray tag. 
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DPBC (Delivery Point Bar Code.) iDformation necessary 
to print the Postnet Barcode on the mailpiece. 

Pull Key Customer Defined key to look up a particular 
mailpiece. 

User Field Customer Defined key for customer use. 
Proc Dir Processing Directives give instructioDS to the 

machine regarding whether to Staple, Seal, Drop 

Inserts, etc on this particular mailpiece. 
Str 0-Str3 Page count information for up to three (3) 

streams of material. Note that these mailpieces only 

have pages firom stream 0. 
Print and Verify String Data for these mailpieces appears 
as follows: 

Print String Data 
Insert Verify String Data 

As the processing of the material progresses, the machine 
begins to send mailpiece tracking data back to the database. 
The data sent back for the accounts listed above could, for 
example, appear as follows: 



10 
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Table 5 shows that mailpieces 3643, 3644, 3644, 3645, 
3646, and 3650 went to destination SH (the "normal" 
mailable destination), mailpiece 3647 was never "seen" by 
the machine (because of a read error, for example), 3648 was 
OR (operator removed) for reason #546 (possibly a jam or 
some other problem), 3649 was diverted to the R2 (reject 
bin) for the same reason (#546). Table 5 also shows that the 
mailpieces were processed during Shift 3 and Joblnstance 
821. The database contains detailed information about the 
processing in the Job and Shift tables. 

Once the machine finishes processing the mailpieces, 
reports are generated that show which mailpieces were 
successful, which need to be reprinted, etc. The reports are 
fed back into the system to start another print run. 

The present invention provides several advantages over 
1^ prior art systems and methods. First, all types of data stored 
in the database driven insertion server are related to the other 
types of data in a way that makes generating very flexible 
and detailed reports very easy. 

Second, since instructions about each mailpiece are stored 
in the database, the instructions can be modified right up 



TABLE 5 



Returoed Mailpiece Tracking Account Data 



Fin. 






Shift 


Job 






Key 




Dest 


Inserts 


Seq 


Doc 


IDF 


Dup 


Dest 


Start Tune 


Finish Time 


ID 


ID 


Weight 


Pos 


tagc Line 


Status 


Rsn 


Fed 


Num 


ID 


ID 


Count 


"Sir 


10/21/199 8 
17:49:47 


10/21/199 8 
17:51:07 


3 


821 


251 






0 


1 


«000" 


"3" 


3643 


160 


0 


-SH" 


10/21/199 8 
17:49:47 


10/21/199 8 
1751K)7 


3 


821 


251 






0 


1 


-000" 


«4" 


3644 


160 


0 


-SH" 


10/21/199 8 
17:49:47 


10/21/199 8 
1751:07 


3 


821 


251 






0 


1 


-000" 


-5" 


3645 


160 


0 


"SH" 


10/21/199 8 
17:49:48 


10/2in99 8 
17-51:07 


3 


821 


251 






0 


1 


"000" 




3646 


160 


0 


-OR" 


10/21A99 8 
17:49:47 


10/21/199 8 
1751:07 


3 


821 


251 






0 


546 


-000" 


-0" 


3648 


160 


0 


-R2" 


10/21/199 8 
17:51:16 


10/21/199 8 
1752:36 


3 


821 


251 






0 


546 


-ooc* 


"0" 


3649 


160 


0 




10/21/199 8 
17:51:16 


10/21/199 8 
1752:36 


3 


821 


251 






0 


1 


"000** 




3650 


160 


0 



The data for table 5 is defined as follows: 

Final Destination The location the mailpiece ended up in 

on the machine. 
Start Time The time the mailpiece began processing on 

the machine. 

Stop Time The time the mailpiece exited the machine. 

Shift ID The shift the mailpiece was processed on. 

Job ID The Job Instance the mailpiece was processed on. 

Weight The final weight of the mailpiece. 

Postage Tte final cost of the mailpiece. 

Keyline The keyline printed on the mailpiece (if any). 

Status The final status of the mailpiece. 

Destination Reason The "reason" the mailpiece went to 

the destination it did. 
Inserts Fed Information about which inserts fed on the 

mailpiece, and explanations of why. 
Sequence NiunberThe sequence number of the mailpiece. 
Ekxniment ID Used to look up/relate DDI data in the 

previous table. 
IDF ID Used to look up/relate DDI data in the previous 

table. 

Di4)licate Count Used to chedc for, and signal duplicate 
accounts. 



until the time the mailpiece is placed on a machine for 
processing. This is sometimes referred to as late binding. 

Third, since all mail piece tracking data is kept in the 
45 database, one of the reports that can be generated is a 
standard postal manifest that details all pieces processed and 
the amount owed the post ofiQce. This is sometimes referred 
to as machine based manifesting. 

Fourth, since the mail piece tracking data tracks all 
mailpieces processed properly and all mailpieces processed 
improperly, a list of mailpieces to re-produce is easy to 
produce. This is sometimes referred to as reprint generation. 

Fifth, the database contains a physical description 
(including a scanned image) of all materials to be used in the 
mailroora. This includes inserts, envelopes, and sheets (of 
paper). No other mail processing implementation known to 
the inventors has the ability to show an image of the 
insert/envelope selected. This feature reduces operator 
errors by showing the operators pictures of the materials 
they should be loading into the machine. This is sometimes 
60 referred to as centralized materials data. 

Sixth, the database contains information about all the 
machines connected to it and the instructions to the 
machines for each job. Thus, there is no need to program 
each machine separately. This is sometimes referred to as 
65 centralized job programming. 

Seventh, the database contains a list of all defined '^bar- 
codes'*. When the user programs a job, he/she has the option 
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of creating a new "barcode" map, or selecting one of the 
already defined ones. There is no need to program the reader 
map on each individual machine. This is sometimes referred 
to as centralized reader code map programming. 

Eighth, since all mail piece tracking data is in the same 
database, production reports can be easily generated to show 
relationships between different machines, operators, shifts, 
and jobs. This is sometimes referred to as centralized 
production/efficiency reports. 

Ninth, since the mail piece tracking data tells which 
inserts are fed for each account, and contains the physical 
descriptions of the inserts, a report detailing the chargeback 
amounts can be produced. This is sometimes referred to as 
centralized inserts chargeback reports. 

Tenth, descriptions of each user's and each users allowed 
privileges is kept in the database, and is managed from a 
single application. This allows management of all operators/ 
users in the mailroom from one central location. This featxu^e 
allows some (well trained) users to have privileges to 
perform certain actions with the equipment that other (less 
well trained) operators would not. The allowed privileges for 
each user/operator is managed completely by the customer. 
This is sometimes referred to as centralized user privilege 
management. 

Eleventh, descriptions of each machine are kept in the 
database. This allows programs like Job Setup to ask ques- 
tions pertinent only to the machines the job is intended for 
It also allows easy access to information about each machine 
without having to look at the machine computer itself. This 
is sometimes referred to as centralized machine definition. 

Twelfth, the database contains a master event log that 
contains all events that may be of interest to a user/customer. 
These events include (but are not limited to) Machine 
Starting, Machine Stopping, User Logged In, User Logged 
Out, Job Started, Job Ended, Shift Started, Shift Ended, Job 
Created, Job Deleted, Job Modified, etc. This is sometimes 
referred to as a centralized event log. 

.^jpropriate computer program code in combination with 
hardware implements many of the elements of the present 
invention. This computer code is often stored on storage 
media. This media can be a diskette, hard disk, CD-ROM, or 
tape. The media can also be a memory storage device or 
collection of memory storage devices such as read-only 
memory (ROM) or random access memory (RAM). 
Additionally, the computer program code can be transferred 
to the appropriate hardware over some type of data network. 

The foregoing is illustrative of the present invention and 
is not to be construed as limiting thereof. Although a few 
exemplary embodiments of this invention have been 
described, those skilled in the art will readily appreciate that 
many modifications are possible in the exemplary embodi- 
ments without materially departing from the novel teachings 
and advantages of this invention. Accordingly, all such 
modifications are intended to be included within the scope of 
this invention as defined in the claims. For instance, the 
architecture described herein is easily extendible to manage 
processes not normally associated with the mailroom. Some 
of these processes include direct billing over the internet, 
print on demand, archiving collections of docimients to a 
CD-ROM, etc. 
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In the claims, any means-plus-fiinction clauses are 
intended to cover the structures described herein as perform- 
ing the recited function and not only structural equivalents 
but also equivalent structures. Therefore, it is to be under- 
stood that the foregoing is illustrative of the present inven- 
tion and is not to be construed as limited to the specific 
embodiments disclosed, and that modifications to the dis- 
closed embodiments, as well as other embodiments, are 
intended to be included within the scope of the appended 
claims. The invention is defined by the following claims, 
with equivalents of the claims to be included therein. 

That which is claimed: 

1. A computer program product for managing database 
driven insertion and mailpiece tracking data, the computer 
program product having a medium with a computer program 
embodied thereon, the computer program product compris- 
ing: 

(a) a server including: 

(i) computer program code for populating a database 
with data comprising a plurality of records including 
instruction sets or handling individual mailpieces; 

{ii) computer program code for accessing the database 
to extract the instruction sets; and 

(iii) computer program code for responding to requests 
for the instruction sets from one or more mail 
processing cHents; and 

(b) a mail processing client including: 

(i) computer program code for reading a key code from 
an individual mailpiece, the key code corresponding 
to a database location containing tl^ instruction set 
for handling the individual mailpiece; 

(ii) computer program code for requesting the instruc- 
tion set for handling the individual mailpiece from 
the server; 

(iii) computer program code for performing at least one 
mail processing task in accordance with the instruc- 
tion set; 

(iv) computer program code for gathering mailpiece 
tracking data and for immediately updating the 
record in the database corresponding to the mailpiece 
being processed in real time as the at least one mail 
processing task is performed to indicate the status of 
the mailpiece in real time; and 

(v) computer program code for forwarding the mail- 
piece tracking data to the server, wherein the server 
can store the mailpiece tracking data in the database. 

2. The computer program product of claim 1 further 
comprising computer program code for generating at least 
one report concerning the performance of at least one mail 
processing task. 

3. The computer program product of claim 1 further 
comprising computer program code for generating at least 
one report concerning the tracking of at least one mailpiece. 

4. The computer prograrn product of claim 1 wherein the 
computer program code for performing at least one mail 
processing test comprises computer program code for per- 
forming mail inserting. 



